Description

This implements the per-page approach we agreed on in #3398. The Project Settings page now behaves differently when you're inside a sandbox: each tab tells you whether your changes will sync on merge, and the UI for some tabs changes shape to match what makes sense for a sandbox (no Delete button, MFA read-only, webhook security managed at the parent level, etc.).

The categorization, agreed in the issue thread:

A few things worth knowing about how this is implemented, because they affected the scope:

The merge layer is already protective. I started worrying that "Local" and "Inherited" were just UI promises and that a user changing data retention in a sandbox would actually push that value back to the parent on merge. After tracing through MergeProjects.merge_project/3 and Provisioner.import_document/4, that turns out not to be the case. The merge document only takes [:name, :description, :env, :color] from the target (not the source), and the provisioner only casts [:id, :name, :description] on the project itself. Project-level fields like requires_mfa, concurrency, retention_policy, history_retention_period, dataclip_retention_period aren't in the cast list, so they never propagate. Webhook auth methods, project_users, and the GitHub repo connection aren't in the merge document at all. I added regression tests in sandboxes_test.exs to lock this in so a future change to MergeProjects or the Provisioner doesn't accidentally start syncing them.

The parent admin floor rule is enforced server-side, not just in the UI. A user who is admin or owner on any ancestor project (walking the parent chain, so admin on grandparent counts) cannot be removed from a sandbox. The UI disables the Remove button with a tooltip explaining why, but Projects.delete_project_user!/1 also raises an ArgumentError if you try to do it directly, so a curl bypass or a future code path can't get around it. There's a unit test covering both paths.

Webhook auth methods stay enforced but can't be managed from the sandbox. Auth methods flow down from the parent and are still applied to the sandbox's webhook triggers, but the sandbox UI points users back to the parent for create/edit/delete. The tab is still present so users can find it; the panel renders a notice and a link to the parent project's webhook security tab instead of the full management table.

Closes #3398

Validation steps

Setup

1. Create a project called Cat Shelter Registry.
2. In Project Settings, set MFA to required on the Security tab and change History Retention to 7 days under Data Storage. We'll use these later to confirm they don't get overwritten.
3. On the Collaboration tab, add a teammate as admin on this project.
4. Go to Sandboxes and create a sandbox called sandbox-test. Open it.

You're now inside the sandbox. Every test below happens from here unless I say otherwise.

1. Sandbox Setup tab (Local)

Navigate to Project Settings in the sandbox. The first tab should be Setup.

What you should see:

• A blue banner at the top: "Changes you make here only apply to this sandbox and do not sync to the parent project on merge."
• The section title says Sandbox setup
• The first card is Sandbox Identity
• Below the description, a line: "Identifies this sandbox within its parent: [Cat Shelter Registry]" with the parent name as a link
• The Export project button is still there
• The danger zone at the bottom reads "The danger zone" with a Delete sandbox button. Clicking it opens a confirmation modal that requires typing the sandbox name; submitting calls Sandboxes.delete_sandbox/2 and redirects to the root project's workflows page with the flash "Sandbox and all its associated descendants deleted"

2. Credentials and Collections (Editable)

These are the two tabs where changes flow back. We'll create one of each in the sandbox now and confirm in step 7 that they show up in the parent after merge.

Credentials

1. Click the Credentials tab. You should see a green banner: "Changes you make here will sync to the parent project on merge."
2. Click New credential, pick any type (raw JSON is quickest), and create a credential called sandbox-only-credential.
3. In another browser tab, open the parent project (Cat Shelter Registry) → Credentials. Confirm sandbox-only-credential is not there yet — it lives only in the sandbox until merge.

Collections

1. Click the Collections tab. Same green banner.
2. Click New collection, name it sandbox-only-collection, and save.
3. In the parent project's Collections tab, confirm sandbox-only-collection is not there yet.

3. Webhook Security (managed in parent)

Click Webhook Security. Instead of the usual auth methods table, you should see a notice that reads something like:

Webhook authentication is managed in the parent project. Methods are shared with this sandbox and enforced on its webhook triggers, but can only be created, edited, or deleted from the parent.

Followed by a link: "Manage them in the parent project ([Cat Shelter Registry])" pointing back to the parent's webhook security tab.

4. Collaboration and the parent admin floor rule

Click Collaboration. You should see a Local banner.

The collaborators table shows the current sandbox members. The teammate you added as admin in step 3 of Setup should also be listed (they were inherited when the sandbox was provisioned).

Now hover over the Remove Collaborator button next to that admin. The button should be disabled, and the tooltip should read:

Cannot remove a user who is admin or owner on the parent project

For comparison, add another teammate to the sandbox as editor (not admin on the parent). Their Remove button should be enabled normally.

5. Security tab (Inherited)

Click Security. You should see:

• A yellow banner: "These settings are inherited from the parent project ([Cat Shelter Registry]) and cannot be changed here."
• The MFA toggle is visible but disabled (cursor shows not-allowed on hover, the switch reflects the parent's value)
• Clicking the toggle does nothing

The value you see should match what you set on the parent in step 2 of Setup.

6. The other Local tabs

Click through Sync to GitHub, Data Storage, History Exports. Each should show the blue Local banner at the top. The forms remain editable. This is intentional: you can change these in the sandbox to support sandbox-specific workflows, but the values do not sync back.

7. Merge: what flows back, what doesn't

This is the part that worried me when I started, so worth confirming hands-on.

Still in the sandbox:

1. Go to Data Storage and change History Retention to 90 days (or anything different from the parent's 7).
2. Go to Setup and change Project Concurrency to 1.
3. Open the parent project's settings briefly and note the starting values — History Retention 7 days, MFA required, no concurrency override.
4. From the Sandboxes page, merge the sandbox into the parent.
5. Open the parent project (Cat Shelter Registry) and walk through each tab.

Credentials (Editable — should sync):

• sandbox-only-credential should now appear in the parent's Credentials tab.

Collections (Editable — should sync):

• sandbox-only-collection should now appear in the parent's Collections tab (per Support sandboxes in collections #4613).

Setup (Local — should not sync):

• Project name and description unchanged.
• Concurrency unchanged (didn't become 1).

Data Storage (Local — should not sync):

• History Retention is still 7 days (didn't change to 90).
• I/O retention / policy unchanged.

Security (Inherited — should not sync):

• MFA is still required (didn't get unset).

Editable categories flow back, Local and Inherited categories don't. That asymmetry is what sandboxes_test.exs locks in at the merge-document/provisioner level.

AI Usage

• I have used Claude Code
• I have used another model
• I have not used AI

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review with Claude Code)
• I have implemented and tested all related authorization policies.
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR